

<!DOCTYPE html>
<html>
<head><title>
	q Construct
</title><style type="text/css">
	/* <![CDATA[ */
	#Menu1 img.icon { border-style:none;vertical-align:middle; }
	#Menu1 img.separator { border-style:none;display:block; }
	#Menu1 img.horizontal-separator { border-style:none;vertical-align:middle; }
	#Menu1 ul { list-style:none;margin:0;padding:0;width:auto; }
	#Menu1 ul.dynamic { z-index:1; }
	#Menu1 a { text-decoration:none;white-space:nowrap;display:block; }
	#Menu1 a.static { padding-left:0.15em;padding-right:0.15em; }
	#Menu1 a.popout { background-image:url("/WebResource.axd?d=vzPadgxBN1mHUTJseLKPHuMxQiTo-po8ONdUMQasd_xcUkhTrCvB8hsRdmQy9TgMZtyLdONAlAJa211rEeGkXwiLauXNY7MkRs9bIdAN08U1&t=638901346312636832");background-repeat:no-repeat;background-position:right center;padding-right:14px; }
	#Menu1 a.dynamic { background-color:White;text-decoration:none; }
	/* ]]> */
</style></head>
<body id="body1">
    <form method="post" action="./q.aspx" id="form1">
<div class="aspNetHidden">
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwULLTEwMDUyNjYzMjhkZGh2sOvOOR9fzrVpipqdWhhRFWzjXivThUtupps9R8C0" />
</div>


<script src="/WebResource.axd?d=PYM5oT4PxGEcjos9hJWJEVsSSMB7mzgwaRFN0sOKxLv-tDp1dUdeXdzi_ygkDaQKTpnn0nxoni3fLgERrxxp8E2YJgV-5z6HMMlinEKk6Ew1&amp;t=638901346312636832" type="text/javascript"></script>
<div class="aspNetHidden">

	<input type="hidden" name="__VIEWSTATEGENERATOR" id="__VIEWSTATEGENERATOR" value="B874D0CD" />
</div>
        <header>
            
            <div id="TitlePanel" style="text-align:center;">
	
                <h1>q Construct</h1>
            
</div>
            <nav>
                <table id="SitePathPanel" align="Center">
	<tr id="SPr1">
		<td id="SPrc1"><span id="SiteMapPath1"><a href="#SiteMapPath1_SkipLink"><img alt="Skip Navigation Links" src="/WebResource.axd?d=fQw1s4IdHefOFb7PLv98MAXpxmUMcwA6Om37mQUCyBI-WFc7TBRIrz5aXHVjSRd2TZibkztIl8zyQXyVP-P8G_l94BJBk_ABKAVyyPNMc2k1&amp;t=638901346312636832" width="0" height="0" style="border-width:0px;" /></a><span><a title="APRS-IS Home Page" href="/Default.aspx">APRS-IS</a></span><span> &gt; </span><span><a title="APRS-IS Technical Specifications" href="/Specification.aspx">APRS-IS Specifications</a></span><span> &gt; </span><span><a title="How to connect to APRS-IS" href="/Connecting.aspx">Connecting to APRS-IS</a></span><span> &gt; </span><span><a title="Server Design" href="/ServerDesign.aspx">Server Design</a></span><span> &gt; </span><span>q Construct</span><a id="SiteMapPath1_SkipLink"></a></span></td>
	</tr><tr id="TableRow1">
		<td id="TableCell1"><a href="#Menu1_SkipLink"><img alt="Skip Navigation Links" src="/WebResource.axd?d=fQw1s4IdHefOFb7PLv98MAXpxmUMcwA6Om37mQUCyBI-WFc7TBRIrz5aXHVjSRd2TZibkztIl8zyQXyVP-P8G_l94BJBk_ABKAVyyPNMc2k1&amp;t=638901346312636832" width="0" height="0" style="border-width:0px;" /></a><div id="Menu1">
			<ul class="level1">
				<li><a title="q Algorithm" class="level1" href="/qalgorithm.aspx">q Algorithm</a></li>
			</ul>
		</div><a id="Menu1_SkipLink"></a></td>
	</tr>
</table>
            </nav>
            <br />
        </header>
        <div id="BodyPanel">
	
            
    <p>
        The &quot;q-construct&quot; is implemented on APRS-IS to add the following capabilities to 
        the Internet APRS transport mechanism.
    </p>
    <ul>
        <li>APRS-IS Entry Identification</li>
        <li>Support for a Future Authorization Algorithm</li>
        <li>Support for Loop Detection</li>
        <li>Support for Automatic Loop Protection</li>
        <li>Compatibility with Existing IGate and Client Software</li>
        <li>Only Server Support Needed for Implementation</li>
    </ul>
    <p>
        The currently defined q constructs are:
    </p>
    <p>
        Server Generated:
    </p>
    <ul>
        <li><b>qAC</b> - Verified login via bidirectional port.<br />Packet was received from the client directly via a verified 
            connection (FROMCALL=login). The callSSID following the qAC is the
            <span style="background-color: #FFFF00">server&#39;s callsign-SSID</span>. This construct is in addition to the TCPIP*/TCPXX* construct currently in place.</li>
        <li><b>qAX</b> - Unverified login.<br />Packet was received from the client directly via a unverified 
            connection (FROMCALL=login). The callSSID following the qAX is the
            <span style="background-color: #FFFF00">server&#39;s callsign-SSID</span>. This 
            construct is in addition to the TCPIP*/TCPXX* construct currently in place.
            <span style="background-color: #FF6666">TCPXX and qAX have been depricated on APRS-IS.</span></li>
        <li><b>qAU</b> - Direct via UDP.<br />Packet was received from the client directly via a UDP connection. 
                        The callSSID following the qAU is the server&#39;s callsign-SSID.</li>
        <li><b>qAo</b> - (letter O) Gated packet via client-only port.<br />Packet was received via a client-only port, the FROMCALL 
            does not match the login, and the packet contains either a ,I or qAR construct 
            where the indicated IGate matches the login.</li>
        <li><b>qAO</b> - (letter O) Non-gated packet via send-only port or indirect packet via client-only port.<br />Packet was received via a client-only port, the FROMCALL
            does not match the login, and does not contain a ,I or qAR or qAo construct (not gated packet).
            <br />Packet was received via a send-only port and the FROMCALL matches the login.
        </li>
        <li><b>qAS</b> - Packet via server without q construct.<br />Packet was received from another server or generated by this 
            server. The latter case would be for a beacon generated by the server. Due to 
            the virtual nature of APRS-IS, use of beacon packets by servers is strongly 
            discouraged. The callSSID following the qAS is the login or IP address of the 
            first identifiable server (see algorithm).</li>
        <li><b>qAr</b> - Gated packet using ,I construct from remote IGate.<br />Packet was received indirectly (via an intermediate server) from an 
            IGate using the ,I construct. The callSSID following the qAr is the callSSID of 
            the IGate.</li>
        <li><b>qAR</b> - Gated packet using ,I construct with verified IGate login.<br />Packet was received directly (via a verified connection) from an 
            IGate using the ,I construct. The callSSID following the qAR it the callSSID of 
            the IGate.</li>
    </ul>
    <p>
        Client Generated:
    </p>
    <ul>
        <li><b>qAR</b> - Gated packet from RF.<br />Packet is placed on APRS-IS by an IGate from RF. The callSSID 
            following the qAR is the callSSID of the IGate.</li>
        <li><b>qAO</b> - (letter O) Gated packet from RF without messaging.<br />Packet is placed on APRS-IS by an IGate from RF which the IGate cannot gate messages to. The callSSID 
            following the qAO is the callSSID of the IGate.
            <br />Receive-only IGates will use this exclusively for all packets gated to APRS-IS.
            <span style="background-color: #FFFF00">Note that receive-only IGates are discouraged on
                 standard APRS frequencies. Please consider a bidirectional IGate that only gates to
                 RF messages for stations heard directly.</span>
            <br />A bidirectional IGate can use this construct to denote packets from stations it will not transmit messages to. These
            might be packets from stations outside the IGate's configured range. These might be translated packets where the station is 
            not APRS capable (e.g. D-STAR station transmitting GPS strings translated via D-PRS spec to APRS by the IGate).
        </li>
        <li><b>qAZ</b> - Server-client command packet.<br />Packet is generated by the server/client/IGate and should not be 
            propagated. The callSSID following the qAZ is the callSSID of the 
            server/client/IGate. This is normally used for connection messages such as 
            messages to USERLIST.</li>
        <li><b>qAI</b> - Trace packet.<br />This packet tells each server to add login 
            identification to the packet. This packet starts with the callSSID of the 
            originating station following the qAI. See algorithm for more details.</li>
    </ul>
    <p>
        Client generated q constructs will be verified if a new authorization algorithm 
        is created.
    </p>
    <p>
        <span style="background-color: #FFFF00"><b>Servers MUST have unique logins from 
                    any other server/IGate/client that insert data onto APRS-IS.</b></span>&nbsp; 
                    This is to prevent packets from being erroneously detected as looping. For 
                    instance, if my server&#39;s login is AE5PL and my weather client is AE5PL, my 
                    server will see ,qAC,AE5PL and consider this packet a looped packet. As 
                    logins can be any combination of 9 alphanumeric characters, this should not pose 
                    a problem.
    </p>
    <p>
        IGates which append IGATECALL,I to the end of packets and which are directly 
                    connected to a server which supports the q construct will have the IGATECALL,I 
                    converted to qAR,IGATECALL, qAr,IGATECALL, or qAo,IGATECALL to support the 
                    extended capabilities of the q construct.
    </p>
    <p>
        Servers will have the ability to selectively enable tracing on all packets 
        through server configuration. This must be used judiciously and only when 
        a loop condition is suspected due to the increased bandwidth demands that 
        tracing creates.
    </p>
    <p>
        q constructs will only appear on APRS-IS and are not to be used elsewhere due to 
        bandwidth considerations.
    </p>
    <p>
        For example, this is what happens to a packet without a q construct which enters 
        the system via a verified connection:
    </p>
    <p>
        Original packet:<br />
        AE5PL&gt;APRS,TCPIP*:payload
    </p>
    <p>
        Packet leaving the server if trace is off:<br />
        AE5PL&gt;APRS,TCPIP*,qAC,AE5PL-JS:payload
    </p>
    <p>
        or, if trace is on:<br />
        AE5PL&gt;APRS,TCPIP*,qAI,AE5PL,AE5PL-JS:payload
    </p>
    <p>
        Here is a similar example where the packet is gated to APRS-IS from RF:
    </p>
    <p>
        Original packet:<br />
        AE5PL&gt;APRS,WIDE1*:payload
    </p>
    <p>
        Packet leaving the server if trace is off:<br />
        AE5PL&gt;APRS,WIDE1*,qAR,AE5PL-10:payload
    </p>
    <p>
        or, if trace is on:<br />
        AE5PL&gt;APRS,WIDE1*,qAI,AE5PL-10,AE5PL-JS:payload
    </p>
    <p>
        <b>Logins used on APRS-IS must not consist of exactly 8 characters from 0 to 9 
                    or A to F as this would indicate a server generated IP address for the q 
                    construct.</b>
    </p>

        
</div>
        <footer>
            <br />
            <div id="FooterPanel" style="font-size:X-Small;text-align:center;">
	
                APRS&#174; - APRS Software and Bob Bruninga, WB4APR.<br />
                Copyright &#169; 2025 -
                <a id="AE5PLmail" href="mailto:pete@ae5pl.net?subject=APRS-IS">Peter Loveall AE5PL</a><br />
                Hosted by
                <a id="AMELink" href="http://www.ametx.com">AME Corp.</a>
            
</div>
        </footer>
    
<script type='text/javascript'>new Sys.WebForms.Menu({ element: 'Menu1', disappearAfter: 500, orientation: 'horizontal', tabIndex: 0, disabled: false });</script></form>
</body>
</html>


